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Abstract 

This paper is a critique of a computer programming language, Carl 
Hewitt's PLANNER, a formalism designed especially to cope with the 
problems that Artificial Intelligence encounters* It Is our contention 
that the backtrack control structure that Is the backbone of Planner Is 
more of a hindrance In the solution of problems than a help. In 
particular, automatic backtrack! n& encourages inefficient algorf thms, 
conceals what Is happenin4 from the user, and misleads him with 
primitives having powerful names whose power Is only superficial . An 
alternative, a programming language called CONNIVER which avoids these 
problems. Is presented from the point of view of this critique. 
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The Problem with PLANNER 

A higher level language derives Its great power from the fact 
that It tends to impose structure on the problem solving behavior of the 
user. Desides providing a library of useful subroutines with a uniform 
calling sequence, the author of a higher level language Imposes his 
theory of problem solving on the user. By choosing what primitive data 
structures, control structures, and operators he presents, he makes the 
imoletnentat ion of some algorithms more difficult than others, thus 
discouraging some techniques and encouraging others. So* to be "good", a 
higher level language must not only simplify the job of programming, by 
providing features which package programming structures commonly found In 
the domain for which the language was designed, it must also do Its best 
to discourage the use of structures which lead to "bad 11 algorithms. 

PLANNERUI Is the language designed by Carl Hewitt of the MIT 
Artificial Intelligence Laboratory* (A subset of PLANNED was rather 
haphazardly implemented by G.J. Sussnan, T. Ulno^rad and E. Charniak* We 
call this operational systen MICRO-PLANNERI 2| . ) PLANNER Incorporates 
three basic ideas; automat i c backtrack control structure, oat tern- 
directed data-base search, and pattern-directed invocation of procedures, 
basically, backtracking is a way of making tentative decisions which can 
be taken back If they don't pan out. The patterned! rocted data base 
search allows the user to ask for the data items called assertions which 
match a given pattern, and Is intimately linked via the GOAL function to 
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pattern-directed procedure Invocation, which gives the user the ability 
to say "Find and run a program whose declared purpose matches this 
pattern. 1 ' This type of program* called a tj hg9 rft PV Is expected to 
instantiate the pattern f sycceed ) „ and thus simulate an assertion. In 
fact. It simulates a whole class of them, since failures back into any 
such theorem cause It to make different choices and succeed with 
di f ferent instances. 

Nov/ these mechanises are related can best be Illustrated by an 
example. The statement (GOAL (7A IN ?C)) 1$ expected to assign the 
quest ion-raarked variables that do not have values already, or fall If it 
can't. Causing a backup to the last decision point In the program, 

GOAL Instantiates its pattern by matching It against successive 
assertions, like (BL0CK2 IN 30X1). If It finds none, or enough failures 
propagate back to the GOAL to use up those It lias found. It call theorems 

with matching patterns, such as; 

■ 

(CONSEQUENT (X Y Z) (?X IN ?V) 
(GOAL <?X IN ?£)) 
(GOAL (?Z IN ?Y)) ) 

which expresses one facet of the notion that IN Is transitive. A PLANNER 
program executing (GOAL (BL0CK2 IN ?B)) first checks to see If it "knows" 
the answer, and If so sets B to it. If not, it binds X to BL0CK2, links 
Y and U, enters the theorem, and looks for a Z containing IH0CK2 and 
contained in some Y« Its net effect is to assign a value to B. 
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If a failure propagates back Into the theorem, it finds another Y 
containing I, and hence generates another Q; enough failures to use up 
those Y's drive It to find another Z;and a few mure will make it end the 
original GOAL fall themsel vqs, Backtrack control structure is the heart 
of this apparatus. 

Automat ic backtracking I s Implemented as fol lows: A PLANNER 
program* as it runs, grows a chronological stack of f *I loolnts each of 
wnlch corresponds to either a side effect or a decision point (a place 
where a choice Is made between several alternative possibilities). A 
failpolnt carries with It all information necessary to reconstruct the 
state of the running process at the time the failpolnt was made. It may 
logically be considered to be a snapshot of that process (though It 
really saves much less than a copy). At some time, the process nay 
decide to fo 1 1 . perhaps because some decision mad<? at a previous decision 
point led tlie program into a blocked state from which there are no viable 
al ternat Ives. The failure then pops off the latest failpoint on the 
chronological stack. If this failpoint was a side effect, then It Is 
undone, and the process continues failing. If this failpoint was a 
decision point, then if there are any remaining alternatives/ execution 
proceeds from that failpoint with th-e next choice taken, or If there arc 
none the failure continues to propagate. In these terms, GOAL finds 
exactly one assertion or theorem each time it Is reached, but sets a 
failpolnt to regain control IF a failure should occur later. 
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For somo time we have been studying PLANNER and Che uses to which 
it has been put, hoping to learn just what modifications would be 
des i rable to the user communi ty» These Investigations have led us to 
decide that this basic control structure of PLANNER Is wrong, though its 
successes Indicate that it contains many powerful (and seductive) Ideas. 
This investigation has led to the design and implementation of a new, and 
hopefully cleaner language, CONIJIVEAl 3 I * built partially on the good 
ideas found in PLANNED, 

Here Is our thesis: automatic backtracking, which occupies a 
place In PLANNED analogous to to that of recursion In LISP, Is the wron/* 
structure for the domain for which PLANNER was Intended, that Is, 
Artificial Intelligence, ita argue that: 

1, Programs which use automatic backtracking are often the worst 
algorithms for solving a problem. 

2* The most common use of backtracking can almost always be 
replaced by a purely recursive structure which is not only more efficient 
but also clearer, both semant leal I y and syntactically* 

3» Superficial analysis of problems and poor programming 
practice ar^ encouraged by the ubiquity of automatic backtracking and by 
the illusion of power that a function like GOAL slves the user merely by 
brute force use of invisible failure-driven looos, 

U. The attempt to fix these defects by che Introduction of 



Sussnan 



"failure messages 11 (to be "explained) Is unnatural and Ineffective. 

Thus we contend that the problem with PLANNER Is automatic 
backtrack control structure. We must stress, however, that PLANNER has 
introduced many valuable constructs Into our way of thinking, the most 
Important of which Is pattern-directed search of a hierarchical data 
base. 

Note also that we ^re not contending that jjood programs cannot be 
implemented In PLANNER; that would be absurd. Ue are only claiming that 
PLANNER sets In the user's way when he tries to embody certain 
straightforward concepts In his programs. Nor are we making the weak 
point that PLANNER occasionally lures foolish proKrammers Into 
Inefficiency. One could try to make this criticism of LISPM* by 
pointing out, for example, how It tempts one to write an exponentially 
exploding, doubly recursive algorithm for computing the nih element in 

the Fibonacci sequence: 

■ 

(uCFUN FIB (H) 

(CO NO ((■» N) 1) 
((- 1 N) 1) 
(T (♦ (FID (- N 1)} 

(FIB (- U 2)))) )) 

The language lias led us astray here, since It discourages writing the 
iterative algorithm, but this Is no condemnation of LISP; the mechanlsn 
of recursive control structure, al Chough the wrong one to use In this 
pathological case. Is often both the most natural and the most efficient 
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control structure for the "problems of symbol ic manipulation that are 
typical of LISP applications. PLAUMErt, however, almost forces 
inefficiency In exactly the applications it was designed for. 

We now consider our points in detail. 

1. All will readily admit that a perfectly clever program would 
do no backtracking; 1c would know where it was gointf at each step and 
never need to undo a bad decision. Good programs that know the structure 
of the problem domain (such as Moses' 5IN|5|1 have no need for an ability 
CO thrash about, searching for a good approach (as in GAINT|G|). Pure 
backtracking (without failure messages) is essentially a mechanism for 
easily undoing a bad decision In the hope that a better alternative will 
be found. Thus it Is most appropriate to algorithms which make such bad 
decisions either because of lack of sufficient guiding structure In the 
problem space or of sufficient knowledge of thdt structure In the 
program. 

It is, of course, impossible In practice or In principle to 
achieve perfect or even adequate knowledge in most Al application 
programs. Inev i tab I y, urograms w! I I recognize that they have gone 
seriously agluy, and will have to undo part of what they have done. 
Unfortunate! y, pure backtracking undoes everything since the last 
decision, without enquiring as to whether It was the one at fault. Such 
a program will eventually stumble upon the rii*ht path, but its 
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organisation makos It hard* For It to learn something from an attempt that 
failed and erased all its side effects* The only attempt at correcting 
this intrinsic defect of failure In the PLANNER sense Is the failure 
message device/ to be discussed under point four. 

2. Observation of the HIT vision ffroup's|7| use of MICRO-PLANNER 
tends to indicate that one of the nore important uses of backtracking, in 
programs which are not searching because they know exactly where they are 
going. Is in in format ion retrieval , Al though Important , It Is curiously 
quice trivial for such a powerful mechanism as the GOAL primitive. 
Vision programs maintain large data bases of Information about a visual 
scene, and often must be able to search out relevant data I terns from a 
mass of irrelevancies. For example: 

(GOAL (?X IS BIG)) 
(GOAL (?X IS GilEEN)) 
(GOAL (?X OU ?Y)) 
(GOAL (?Y IS BLUE)) 
( stuff ?X ?Y) 
• 

means "do the stuff' 1 on the first objects X and Y such that "the bl« 
green X Is on the blue Y." If stuff doesn't like the first ones found, 
it can easily fall to get nore. If there are any. Note that what Is 
going on here Is sequential filtering of the possible assignments of X 
and Y by pattern-directed search of the data base and theorems. We see 
chat backtracking roust be used here because any particular hi", k chosen 
on line one may not be ftreen, or may not be on something blue. The stack 
frame of each goal statement thus maintains a list of the hitherto 
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untried possibilities and I f a failure reaches It, It tries the next one 
and proceeds. 

A much more straightforward and revealing approach would be to 
use ordinary recursive and Iterative control structure to filter the 
possibilities directly. Thus, for example, a LISP function FOR-ALL might 
be written, such that: 

(FOK-ALl <?X IS BIG) 

(FJR-ALL (?X 15 GREEN) 

(FOR-ALL (?X ON ?Y) 

(FOit-ALL (?Y IS BLUE) 
fstuf f?X ?Y))))) 

would have the desired effect. Here, FOil-ALL Is just a standard LISP 
function which, upun 00 try/ looks up all of the assertions and theorems 
match I mi; tne pattern j;l veil as Its f I rst argument (wt ch val ues substituted 
for variables which are already assigned). It then assumes the first 
possibility, assigning variables appropriately, and evaluates Its second 
argument. If the evaluation ever returns, rather than exiting the loop, 
the f I rst element is removed from the list of posslbi I 1 ties and the 
process repeats. Notice that by appropriately nesting our loops no 
backtracking Is required in the data retrieval. HfStfl stuf f Is done on 
each X and Y which satisfies Che criteria until stuff decides it has had 
enough* and leaves the nest of FOR-ALL's (with a RETURN, GO, or something 
si mi lar) . 

This good nesting of loops has decided advantages. Besides being 
more efficient than backtracking {a marginal advantage), good nesting 
manes the scope of the action clear. There Is no chance an unexpected 
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failure will propagate back Into thisode and compute without our 
explicit programming of this activity* 

We want to enphasize that this insidious problem Is not made up. 
It is observed by real users of MICRO-PLANNER who complain that they just 
can't control their programs because what chey do depends on events 
before and after they are called* Usually any choice made In a piece of 
code doing such filtering eventually fails for the same reason that the 
first choice did, but backtracking tends to treat all decision points as 
equal I y Important and tries al 1 puss I bi I I ties; the onl y subsequent 
symptom that the program Is running amok is that It takes forever to tell 
you it failed. The consequent theorem given suffers from exactly this 
problem; if called by, e.g., (GOAL (BL0CK2 IN D0X1)), its only possible 
actions are either to find a Z between UL0CK2 and B0X1, or to fail 4 
Although which L is found cannot possibly affect subsequent events, a 
failure back to the theorem will cause It to look up another Z, succeed, 
and allow its caller to fail again in exactly the same way! 

One way out of this problem is to FINALIZE the program from just 
before the first filter to just after the code which the user doesn't 
want reentered upon failure, thus freezing all Its side effects once and 
for all. This Is unsatisfactory because often some of them should be 
undone upon some later fa! lure. 

In some cases this Is a problem, in some cases not; what Is 
always a problem Is that tne structure of a PLANNER program does not 
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reveal what che prograiwner ' s intentions are. lie must always keep In mind 
chat In effect there is only one gigantic nest of failure-driven loops In 
any PLANNErt program, and every subprogram that might fail is only a tiny 
piece of It, We think that It is essentially clearer for any looping or 
nesting structure to be made explicit* 

J. As PLANNED Is currently organized. It provides a very compact 
notation in which to encode exhaustive searches for solutions to problems 
tne programmer understands poorly. Other program organizat ions, though 
certainly possible, are clearly more complex and less transparently 
described. To overcome this difficulty, a multiprocessing capability 
has been patched Into PLANNER in later versions, but several backtracking 
processes do not seem any better than one. Multiprocessing allows 
*'breadth-wi se search" of a sort, but it Is only an abortive step to 
freedom by the poor programmer. Each of his processes Is still crippled 
by the exhaustive searches built Into system primitives; he must still 
spend t ime cal culat I ng the possi ble directions from and ci rcumstances 
under which control could enter each line of his code. With all the 
machinery hung on his programs to circumvent the control structure, they 
look much less understandable; most programmers just can't be troubled. 
There Is really no reason why they should be. Me have already made the 
point, which we can carry much further, that a more revealing control 
structure would allow programmers to express a broader range of concepts 
more natural ly« 
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There Is d deeper issue here Chan what Is needeH in PLANNER to 
make It more powerful; we ask instead what It Is about PLANNER that makes 
it so unusable. Its defaults are chosen throughout so that backtracking 
must be tediously reckoned with In every case unless the user explicitly 
prevents it. It is easy to say (as some PLANNER advocates do) that 
people should write their programs to avoid the temptation to backtrack 
except when necessary, but It is much harder actually to do It when the 
language gives them Qverv opportunity to fall* 

It* In order to ?ive the user a modicum of control over the 
backtrack mechanism, failure messages v/ere incorporated into PLANNER 
early in its history. The intent was to give a program the ability to 
fail with any message to a specific point which It has set up beforehand 
co catch the failure by matching that message. This does not give the 
user the ability to perform even the simplest of control functions. 
Suppose, for example, we have a >;oal which Invokes a theorem. This 
theorem, in probing the search space., di scovers something relevant to Its 
further exploration. It would like to edit the list of theorems which 
are pending in the goal which called It (the alternatives which will be 
tried If the current theorem falls), deleting some entries and inserting 
others. It might even wish to sort the list of alternatives according to 
some general criterion. It has not yet, however, failed, and thus cannot 
return a failure message. Furthermore, It cannot Ret at the list of 
al tenia ti ves pending on Its f al lure. 
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This Is not a fine point of control structure theory; It would be 
extremely relevant to a PLANNER encoding of a chess program like that of 
Greenbl att I 8| * For example/ this program/ In an analysis of a move/ may 
discover that It Is In danger of being forked. This discovery must 
change the whole set of criteria by which It judges further alternatives. 
It must try to make a move which meets the discovered threat/ if 
possible. 

Ue have been concentrating here on the sloppy interface between 
failure messages and GJAL, but there is a fundamental difficulty with 
them that would be encountered even If the user abandoned GOAL 
altogether. That Is, they can't carry enough information. There is no 
way to fall back with the message; ''Process P ran Into difficulty T/ 1 ' 
because process P and its context have been destroyed by the failure. So 
all the relevant Information must be contained in the T part of the 
message: ''Difficulty T, ,f It Is clear that including all and only the 
relevant Information is as Impossible a job for a subroutine as 
anticipating the form of every possible failure \s for Its caller. In 
fact, the THMESSAQE primitive of MICRO-PLANNER has never been 
successfully used; it seems to be one of those superficially good ideas 
that prove to be unworkable. 

It seems that a failing program has no choice but to make too 
mucfi information frozen in too global a context/ or to flush everything 
It has discovered and bet all its chips on one message it hopes somebody/ 
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somewhere, can figure out. These alternatives do not really alter the 
blind nature of a failure-driven process, or of several of them. This is 
probably why they no unused. 

At this point It Is desirable to abstract our entire discussion 
away from the particular primitives of PLANNER, and enquire what is 
gained and what is lost by the use of automatic backtracking* What Is 
gained is clear, and very appealing. In the first place, It provides a 
mechanism for eenera t ln& alternatives, one at a time, to be used In an 
effort to accomplish some task. Secondly, It provides a mechanism for 
eradicating the consequences of accepting an alternative later found to 
be unsu j tabl e • 

4/e have criticized the consequences of this scheme In several 
ways already. How we shall argue chat Its basic defect Is that It forces 
the dangerous assumption that the alternatives at each decision point are 
Independent; that (as within all PLANNER primitives) the trial of one of 
them may produce little or no Information which can influence the 
selection of further alternatives, or the way in which they ans run. 
This is enforced by the eradication of the consequences of a hypothesis 
when that hypothesis Is discarded. 

For example, a robot wants to pick up an object, and he has 
several ways of doing so. In trying the first method, with his right 
hand, he discovers Chat the object Is hot by seriously burning himself. 
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It Is clear chat though this method failed he should noc go back and try 
his left hand. Hor should it be necessary for him to have foreseen the 
difficulty and thus set up a message catcher for burnt hand failure (or 
for lightning striking); such caution, applied to all possible 
contingencies/ is Impossible. The reasonably designed robot will 
drastically modify his behavior at this point/ say by getting a pair of 
tongs, after screaming. 

notice also that any failure-driven generator (a function that 
returns a value but sets a fallpointj is constrained to generate 
alternatives one at a time. If the alternatives are Interdependent/ 
surely the best one should be chosen while all or most are In view. In 
fact/ the only reason for generation objects rather than just making a 
list of them Is that sometimes the number of possibilities (as, say, the 
prime numbers) nay be Infinite/ or the cost of generation of the next 
possibility is much greater or grows much faster than the cost of testing 
its usefulness. In many cases, however/ an explicit list of all or some 
of the alternatives is what is desired. Of course/ even In PLANNER/ such 
a list must exist, snuggled inside some GOAL's fallpotnts, but there Is 
no natural way to get at It. 

The PLANNED Implementation of pat tern-di re c ted procedure 
invocation reinforces these problems of uacktracki ng. The anonymity of 
the procedures that may be fetched by pattern-directed call makes it even 
easier to pretend to have many "independent" methods of solving the same 
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problem, hoplnc that one of the methods* to be found by failure, will 
come up with an acceptable solution. Not only does this organization 
force each method to have to be able to run In complete Ignorance of what 
has been tried so far, or even that other methods exist/ but In many 
cases the "independent" methods will come up with the same unacceptable 
answer more than once, causing the system to thrash ridiculously. The 
solution, of course. Is to abandon the myth that there could be several 
Independent methods of attacking any interesting problem, and concentrate 
on techniques for making methods Interact reasonably. 

This Is not to say that the pattern-directed function call does 
not have Its place In the arsenal of problem solving. It is valuable 
whenever, either due to the infiniteness of the set or the economics of 
storage vs. computation, a procedure can be used to represent a set of 
assertions. 

There are several such reasonably ^ood ideas scattered throughout 
PLAHHEtl. They include the notions of "generator" and "possibilities 
list." Out they have been pushed far beneath the surface, so that that 
the user may think in terms of "goals," Uhile the concept of goal- 
directedness Is certainly as well established as any In our field. It 
seems clear that naming a primitive function "GOAL" is not enough to 
capture the essence of the Idea. In the next section, we shall 
concentrate on the decent Ideas in PLANNER, and discard those that have 
tfotten su many MICRO-PLANNER users In trouble, starting with automatic 
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backtracking. 
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Building CONNIVES 

We have shown In the first section that backtracking Is a device 
of questlonaule usefulness at the very tasks for which It was designed. 
It encourages d linkage of the mechanism for generating alternatives with 
the mechanism that restores the environment after the investigation of 
each one. Each time, the generation of the next must proceed on the 
basis of very little information besides the fact that the last failed. 
rfe have. In the end, a control structure that almost forces the user to 
regard all his problem->sol vlng methods as independent. 

It seems to bo the linkage of these two mechanisms In the GOAL 
statement that Is at fault. As an alternative, imagine that we are not 
allowed to use failure to clean things up, and that everything each goal- 
dlructed subroutine does stavs done. Than* If the speculation it has 
indulged in is not to have effects In the environment of Its caller (the 
program considering the alternatives), it must have a lgcfll qnYlrflfl merit 
of its own to make changes to. These changes may make Its model of the 
problem conflict with its superior's model, or may simply be hypothetical 
additions to It. The Important point Is that a simple return to the 
caller will be sufficient to make the changes invisible. 

This concept can be made clear by analogy with the familiar 
notions of "control environment" (a stack, for example), and "access 
envi ronriient" (where variables are bound; the term Is 3oi>rnw and 
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iJG£breit's| 9| ) ; in CONNIVED we generalise the latter to "data base 
envi roniiient," or context. Just as LISP 1.5 supports a tree of access 
environments ("association llsts") / so DONNIVER supports a tree of 
contexts, in which each daughter-context represents a data base 
Incrementally different from her parent. 

This tree. It will be made clear, must be Brown and maintained In 
conjunction with a control environment of equal complexity. But the 
control structure exists only to exploit the data base, so we return to 
It later. 

Conniver contexts contain i tefi^ which are simole list structures 
like PLANNERS assertions (without the theorem-proving connotations that 
surround the latter term). An Item such as (SQUArtE'*8 PAWN3) may be added 
to the current context with 

(AJD f (SQUADS PAHN3)) 
and taken out wi th 

(REMOVE '(SQUAHEU8 PAWH3)), 
The arguments to ADO and REMOVE aro skel eton^ , list structures that 
define i tens after substitution of the values of their variables. 
Variables are indicated by ",". Thus, If X • PAwH2, (ADO '{SQUARED ,X)) 
adds the Item (SQUAiCCbg PAWN 2) to the current context. 

Now, if the presence or absence of an item Is to be reflected 
on I y In a local data base, that is, he "hypo t he t i cal ," the data 
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environment must be "pushe'd down" before doing ADD's and REMOVE'S of this 

sort. Since, In CONUIVER, a context Is a data type, and the current 

context Is assigned to the variable CONTEXT, all we need to write Is: 

(PrtOG "AUX" ((CONTEXT ( PUSH-CONTEXT) ) ) 
(AJO *(SQ0Ail£I.8 PAWNS)) 

'. ) 

CONNIVE.* syntax is roughly chat of LISP, but a declaration of local 
variables must be explicitly Indicated with the atom "AUX", and each such 

local Must be given an explicit Initial value. If it Is not to be 
unasslgned, by bain? declared as "(variable value)" Instead of just 
"variable." This P.IUG thus rebln.K CONTEXT to the value returned by the 
system function PUSH-CONTEXT. The current context has had one more 
.C-QJU^^C-Xjl-Jiltt pushed onto it. New changes apply to this frame only. 
After the body of the PrtOG has been executed In this "hypothetical" 
context, the PHOG's control frame will be exited. CONTEXT will be 
unbound, restoring its old value. In which the action of the ADO Is 

invisible; In effect, a data f rame . has been exited as well, 

- 

Since contexts are data structures just like lists, they can be 
returned as values of functions, assigned to global variables, etc., so 
that in fact the user has available a tree of contexts his program has 
left behind. In the sat.ie way that us line functional arguments (closures of 
functions) In LISP creates a tree of variable-value associations. 



Sussman 23 



I cams can be retrieved from the current context by neans of the 
CdNNIVER primitive FETCH, which finds all items present in the context 
that match a pattern. For example. If we let the presence of the Item 
(HAS player square) means "player (X or 0) has put his mark In square In 
the tlc-tac-toe position represented by the current context, 11 we can find 
all of X's squares with 

(FETCH '(HAS X 7SQUARE)). 
.toujjhly as In PLAIMEA, the "7" indicates that the variable SQUARE is to 
be assigned a value by matching the pattern (HAS X ?5QUARE) against some 
Item. However, FETCH docs not makes the assignment. Since backtracking 
has been exorcised from COUNIVER, It simply returns a ^ flgslbl 1 1 1 les l .l ?£ 
which contains al 1 the matching Items, rather than hiding them In a 
fuilpoint in GOAL, to be handed to us coyly, one per failure. 

Such a possibilities list might look like 

(*PJSoliJlLITIES 

<*ITEM ((HAS X 5) (9 +)) ((SQUARE 5)J) 
(*ITEil ((HAS X 2) (9 +)) ((SQUARE 2))) ). 

The exact Meaning uf nv^iry parenthesis In this list Is unimportant, but 
the overall content is this: FETCH has found two i tern nossi bl 1 1 1 les .. both 
present In this context {which Includes context-frame 9). The first 
matches the pattern with SQUARE = 5; the second, with SQUARE = c. 

The user can manipulate this list In any way he chooses; one way 
is with the system function TRY-NEXT., which pops off and returns the 
first Item In the list (here, ((HAS X 5) (9 + ))), and assigns the pattern 
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variables as the possibility directs (and so, in this case, sets SQUARE 
to S). 

How can we exploit this data structure? Although PLANNER, In Its 
latest Incarnat ions| 1Q| , contains a data base structure as powerful as 
what we have sketched. It should be clear that Its backtrack mechanism Is 
worthless for the purpose; It often destroys exactly the contexts we wish 

to preserve, 

■ 

For the present, we want to stick to the simple problem of 
generating al ternat Ives, which PLANNER Is constrained to do one at a 
time, one per failure, erasing part of the generator's context each time. 
If the generator wishes to communicate the fact that It has failed so 
far. It Must destroy Its context entirely to do it, even though It may 
have just succeeded In building a useful world model. The best that can 
be said for failure Is that It has become Irrelevant, since If 3 process 
does want to throw in the towel completely, all it has to do Is return, 
unbinding CONTEXT. To use CONNIVED data structures effectively, we need 
a compromise between keeping a failpolnt and returning for good; let us 
al low a generator to return, but Jk£££ I ts con t ml envl ronnep t In 
ex 1 stence* Since that control environment uay include a binding of 
CONTEXT, it Includes some data environment as well; It can be used to 
embody a noirjr of view towards the program's problem and a place to go to 
attack it further. 



Sussman 25 



This mechanism becomes Important when a program wishes to Include 
a set of Items in the current context on the basis of a procedural 
criterion instead of their actual presence. This is essentially the role 
of consequent theorems in PLANNER* but the analogous CJNNIVEIt structure, 
the 1 f - needed method, cannot work the way consequents do because there Is 
no backtracking. An If-nueded which matches a FETCH'S pattern will be 
found after all the matching Items, and included in the possibilities 
list as a method possi bl I i tv , of the form (*METHOD pattern method). Uhen 
TMY-NEXT encounters such a thing. It must Invoke It. An if-needed, once 
invoked, acts as much like a generator as Its consequent-theorem cousin, 
but in a different way. 

Pursuing our tic-tac-toe example, let the presence of th*» I ten 
(•-JliJMOVE player square move) mean "player (X or 0) will have three narks 
In a row If he makes move, after occupying square." Such items might come 
in handy, for example. In a search for £wq winning moves after the 
occupation of square; since the opponent cannot block both, occupying 
square will force a win. 

For example, a COMNIVErt program may search for moves M which win 
the tjaMe for X after his occupation of square 3 with (FETCH '{IflNMOVE X 8 
?M)). If the resulting possibilities list includes {^METHOD (IJINilOVE X 8 
?a) MINI-HIVES), the Method LJIHM0VE5 will be invoked by TKY-NEXT: 
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( IF-MEEDED '.JIHMOVES 

UUMOVE 7PLAYEH 7SQUARE ?MOVE) 

"AUX" (PLAYER SQUARE MOVE (CONTEXT (PUSH-CONTEXT)) PI SQ1 P2 GQ2) 
[ADD '(HAS ,PLAYE1 ,SQUA;1E)) 
(REMOVE '(FREE , SQUARE)) 

(CSETQ PI (FETCH '(HAS , PLAYER ?SQ1))) 
rOUTERLOOP 

(TRY-NEXT PI '(GO 'END)} 

(CSETQ P2 (FETCH '(HAS , PLAYER ?SQ2))) 
: IHNERLOOP 

(TRY-NEXT P2 '(GO *OUTERLOOP>) 
(CONO ((AND (LESSP SQ1 SQ2) 

(CSETQ MOVE (TIIIRO-I H-ROH SQ1 SQ2)) 
(PRESENT '(FREE ,MOVE))) 
(NOTE (INSTANCE))) ) 

(GO ' IHNERLOOP) 
:E,JO 

(AOIEU) ). 

Whan WIJU0VE5 is Invoked, It pushes CONTEXT down, and supposes 
chat PLAYER owns SQUARE, and chat It Is no longer free. The two nested, 
TRY-NEXT-drl ven loops then consider each pair of squares owned by PLAYER, 
setting SQ1 and SQ2 at statements :OUTERLOOP and lIMNERLOQP, 
respectively. (Atoms used as labels must be prefixed with the character 
":".) The second argument to each TRY-NEXT is evaluated when its 
possibilities are exhausted. THIRO-IN-ROW is a function that returns the 
third square In the row, column, or diagonal of .Its arguments, or NIL If 
they are not collinear; (PAESENT oattern) Is nun -NIL only If an I ten 
matching pattern Is present In the current context. 



Mere is how JIHMOVES works: for each distinct pair of collinear 
squares owned by PLAYEii, If the third square is free, the INSTANCE formed 
by substituting the current value of HOVE into the pattern used to call 
WliJMOVES !b iJOTEd. (I.e., it is saved on a list, accessible to the user. 
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whose structure need not concern us here. ) When all the I nstances 

(which look just like item possibilities) have been found, they are 

packaged by (AJIEU) into a possibilities list, which Is returned. It 

mlgh t look 1 i ke 

(•POSSIBILITIES 

t * I TEH ((WINMOVE X 3 5)) (CM 5))) 
(•ITEM (CUINMOVE X 3 5)) C(M 3))) ). 

The list which ADIEU creates is returned to the TRY-NEXT that 
Invoked W I (MOVES, This TRY-NEXT has been manlpuiat ing our original 
possibilities list/ generated by (FETCH ' (UIWIOVE X 3 7M)) ; It found 
MINHOVES In the list and invoked it, and tt now has Its value, a new list 
of possibilities. It does Che obvious: It splices the list the method 

returned into Its I 1st In place nf UIMHOVES, Thus, the original 
generator possibility In the list has been nade to stand for the 
possibilities It can produce when invoked. WINMOVES stands for a set of 
winning noves not mentioned explicitly in the data base. 

Our concept of generator appears simpler than PLANNER'S; 
WINMOVES dui.tps all the instances into the upper possibilities list and 
returns, leaving its control environment and binding of CONTEXT to be 
collected as garbage. Even if Its caller wants only one new item 
possibility, generators like WINMOVES give him all of them. 

We have returned to our original problem: how can we maintain in 
existence the control and context structure of UlfJMOVES while returning 
fro*.i it with only a few of the possibilities It can find? The answer 
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lies in the structure and function of the possibilities list; to Invoke a 
method found In such a list is to rgol *ico the method by its value, itself 
a 1 i st of possibl 1 I ties. If this value list contains a general I zed tag 
back to the generator's activation, its environment will be preserved* 
Hot only that, but If TrfY-NEXT comes uoon such a thing In a possibilities 
list, it Is bound to GO to It- Mow the method can generate items In 
finite groups, asking to be reawakened If none of the Items satisfies Its 
caller. A new version of WINMOVES that works this way (and has been 
st reai-il Ined In other respects) looks like: 

(IF-HEEOED UIHI4UVES 

(UIUMOVE 7PLAYEH 7SQUARE ?HOVE) 

"AUK" (PLAYER SQUARE MOVE (CONTEXT (PUSH-CONTEXT)) SQ1 SQ2) 

(AOD '(HAS ,PLAYEil , SQUARE)) 

(REMOVE '(FREE , SQUARE)) 

(FOR-EACH (FETCH '(HAS ,PLAYER ?SQD) 

(FOR-EACH (FETCH '(HAS ,PLAYEll 7SQ2)) 
(COND <(ANU (LESSP SQ1 SQ2) 

(CSETQ HOVE (TH!RD~tN-ROU SQ1 SQ2J) 
(PRESENT '(FREE ,M0VE))) 
(NOTE (INSTANCE)) 
(AU-REVOIR)) ) )) 

(ADIEU) }. 

Aside from the use of FOR-EACH as a shorthand for a TRY-NEXT-dr I ven loop, 
the only addition Is (Ad-REVOIR) following (NOTE (INSTANCE)). AU-REVOIR 
is just like ADIEU, but adds a tag to its own activation at the end of 
the possibilities list It returns. Now iIINMOVES IJOTEs and returns iuit 
Qfltt instance each time, but if the Instance is unsatisfactory, is 
reawakened at the end of the Inner FOR-EACH, to aeneratc oni* more the 
same way* (Note that on such returns to an activation. It Is the tac AU- 
REVOIR left In the upper possibilities list that stands for a list of new 
items; GOim; replaces it with a possibilities list from the qeneratur 



Sussman 29 



just as Invoking does with method possibilities.) 

The requirement that there be general izori £a&S/ tags that mention 
whole control environments, makes it necessary that QONNIVER maintain a 
control tree similar in structure to the context tree It serves. All 
such stl 1 1 -viable environments form a set of processes cooperating to 
solve a problem. Some of these are generators, using possibilities lists 
as communication channels with their callers, but this by no means 
exhausts the alternative ways of Interacting. In particular, CONNIVEK's 
generalized con cm] strucrure makes it easy to put all of failure and 
backtracking back In if the user want? them, but he has the duty (or 
privilege) of desiring and maintaining control over what he builds, 

A couple of points remain to be nude, Notice that, although the 
loops in J I (MOVES are exhaustive and blind, chev are nxnl I <; ! t . The only 
natural way to write this generator in PLANNER is by use of successive 
GOAL statements that filter out the bad choices. Although the user may 
intend a loop like a FOR-EACH, and, locally, the, GOAL conglomeration 
behaves like one, it suffers uncontrollably from the effects of global 
f ai lures. 

Generators do not have to be nethods; we have only hcen pursuing 
chis example because of the PLAHIJE3 analogy; it seems nuch morn rational 
that UIIJilOVES In particular be a funqtjq n of two arguments, PLAYER and 
SQJArfE, with values corresponding to MOVE. (5ee 121.) 
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Communication between processes/ U Is our feeling, is essential 
to their success. We have Cried to build as r.iany communication devices 
Into TRY-NEXT and Generators as possible In hopes that the/ will be used. 
It would be very dangerous to try extending the exhaustive searches used 
in UKJMOVES to something as much more complicated as a plausible chess 
move generator, A clever generator must be able to talk to Its caller. 
MINMOVES is supposed to illustrate what Is legal in COHNIVER, not what Is 

£DOd. 

LJe have constructed CQHNIVEft partly by raising to prominence 
ideas casually embedded In PLANNER, partly by giving hidden PLANNER 
constructs back to the people/ and partly by concentrating on what Is 
needed in a programming language as opposed to a theoreni-prover. Our 
major contribution, we think/ Is the elimination of backtracking upon 
failure as a mechanism for the blind generation of alternative approaches 
to a problem. We have shown how PLANNER makes It difficult to write 
controllable programs; how, like most theurem-provers. It Is committed to 
loosely guided exhaustive search as a problem-solving method; and how t lie 
user must either succumb to the will of the control structure or spend 
much of his time using primitives {like FINALIZE, STIZAI GIlTEN, TEMpnoG, 
a Jjjj ad Inf Ini turn ) that save him from it. It Is our hope that we have 
shown that control and understanding of his programs should be vital 
concerns of the Artificial Intel I i^ence pro^ranmer. 
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